ebab7d0da53c51438720d60c6e2e467c - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Coupling (computer programming)</title>

</head>

Coupling (computer programming)

</h1>

</header>

In <a href="Software_engineering" title="Software engineering">software engineering</a>, coupling is the degree of interdependence between software <a href="Modular_programming" title="Modular programming">modules</a>, a measure of how closely connected two routines or modules are,<a href="#cite_note-ISO_24765-1">[1]</a> and the strength of the relationships between modules.<a href="#cite_note-ISOIECTR19759_2005-2">[2]</a> Coupling is not binary but multi-dimensional. <a href="#cite_note-:0-3">[3]</a>

Coupling is usually contrasted with <a href="Cohesion_(computer_science)" title="Cohesion (computer science)">cohesion</a>. <a href="Loose_coupling" title="Loose coupling">Low coupling</a> often correlates with high cohesion, and vice versa. Low coupling is often thought to be a sign of a well-structured <a href="Computer_system" class="mw-redirect" title="Computer system">computer system</a> and a good design, and when combined with high cohesion, supports the general goals of high <a href="Computer_programming#Readability_of_source_code" title="Computer programming">readability</a> and <a href="Maintainability" title="Maintainability">maintainability</a>.

<div class="mw-heading mw-heading2"><h2 id="History">History</h2></div>

The <a href="Software_metric" title="Software metric">software quality metrics</a> of coupling and cohesion were invented by <a href="Larry_Constantine" title="Larry Constantine">Larry Constantine</a> in the late 1960s as part of a <a href="Structured_design" class="mw-redirect" title="Structured design">structured design</a>, based on characteristics of “good” programming practices that reduced maintenance and modification costs. Structured design, including cohesion and coupling, were published in the article Stevens, Myers & Constantine (1974)<a href="#cite_note-Stevens_1974-4">[4]</a> and the book Yourdon & Constantine (1979),<a href="#cite_note-Yourdon_1979-5">[5]</a> and the latter subsequently became standard terms.

<div class="mw-heading mw-heading2"><h2 id="Types_of_coupling">Types of coupling</h2></div>

Coupling can be "low" (also "<a href="Loose_coupling" title="Loose coupling">loose</a>" and "weak") or "high" (also "tight" and "strong"). Some types of coupling, in order of highest to lowest coupling, are as follows:

<div class="mw-heading mw-heading3"><h3 id="Procedural_programming">Procedural programming</h3></div>

A module here refers to a subroutine of any kind, i.e. a set of one or more statements having a name and preferably its own set of variable names.

<dl><dt>Content coupling (high)</dt>

<dd>Content coupling is said to occur when one module uses the code of another module, for instance a branch. This violates <a href="Information_hiding" title="Information hiding">information hiding</a> – a basic software design concept.</dd>

<dt>Common coupling</dt>

<dd>Common coupling is said to occur when several modules have access to the same global data. But it can lead to uncontrolled error propagation and unforeseen side-effects when changes are made.</dd>

<dt>External coupling</dt>

<dd>External coupling occurs when two modules share an externally imposed data format, communication protocol, or device interface. This is basically related to the communication to external tools and devices.</dd>

<dt>Control coupling</dt>

<dd>Control coupling is one module controlling the flow of another, by passing it information on what to do (e.g., passing a what-to-do flag).</dd>

<dt>Stamp coupling (data-structured coupling)</dt>

<dd>Stamp coupling occurs when modules share a composite data structure and use only parts of it, possibly different parts (e.g., passing a whole record to a function that needs only one field of it).</dd>

<dd>In this situation, a modification in a field that a module does not need may lead to changing the way the module reads the record. To illustrate the concept of stamp coupling, consider a scenario involving a <code>UserProfile</code> <a href="Software_component" title="Software component">component</a>. This component is designed to return the entire user profile information in response to <a href="HTTP" title="HTTP">requests</a>, even when <a href="User_agent" title="User agent">consumers</a> only require a specific <a href="Attribute_(computing)" title="Attribute (computing)">attribute</a>. This practice exemplifies stamp coupling, which can lead to significant <a href="Bandwidth_(computing)" title="Bandwidth (computing)">bandwidth</a> issues, especially at scale. When any attribute within the <code>UserProfile</code> component changes, all consumers that interact with it may need to undergo <a href="Software_testing" title="Software testing">testing</a>, even if they do not utilize the modified attribute. <a href="#cite_note-6">[6]</a></dd>

<dt>Data coupling</dt>

<dd>Data coupling occurs when modules share data through, for example, parameters. Each datum is an elementary piece, and these are the only data shared (e.g., passing an integer to a function that computes a square root).</dd></dl>

<div class="mw-heading mw-heading3"><h3 id="Object-oriented_programming">Object-oriented programming</h3></div>

<dl><dt>Subclass coupling</dt>

<dd>Describes the relationship between a child and its parent. The child is connected to its parent, but the parent is not connected to the child.</dd></dl>

<dl><dt>Temporal coupling</dt>

<dd>It is when two actions are bundled together into one module just because they happen to occur at the same time.</dd></dl>

In recent work various other coupling concepts have been investigated and used as indicators for different modularization principles used in practice.<a href="#cite_note-Beck_2011-7">[7]</a>

<div class="mw-heading mw-heading4"><h4 id="Dynamic_coupling">Dynamic coupling</h4></div>

The goal of defining and measuring this type of coupling is to provide a run-time evaluation of a software system. It has been argued that static coupling metrics lose precision when dealing with an intensive use of dynamic binding or inheritance.<a href="#cite_note-Arisholm_2004-8">[8]</a> In the attempt to solve this issue, dynamic coupling measures have been taken into account.

<div class="mw-heading mw-heading4"><h4 id="Semantic_coupling">Semantic coupling</h4></div>

This kind of a coupling metric considers the conceptual similarities between software entities using, for example, comments and identifiers and relying on techniques such as <a href="Latent_semantic_indexing" class="mw-redirect" title="Latent semantic indexing">latent semantic indexing</a> (LSI).

<div class="mw-heading mw-heading4"><h4 id="Logical_coupling">Logical coupling</h4></div>

Logical coupling (or evolutionary coupling or change coupling) analysis exploits the release history of a software system to find change patterns among modules or classes: e.g., entities that are likely to be changed together or sequences of changes (a change in a class A is always followed by a change in a class B).

<div class="mw-heading mw-heading2"><h2 id="Dimensions_of_coupling">Dimensions of coupling</h2></div>

According to Gregor Hohpe, coupling is multi-dimensional:<a href="#cite_note-:0-3">[3]</a>

<ul><li>Technology Dependency</li>

<li>Location Dependency</li>

<li>Topology Dependency</li>

<li>Data Format & Type Dependency</li>

<li>Semantic Dependency</li>

<li>Conversation Dependency</li>

<li>Order Dependency</li>

<li>Temporal Dependency</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Disadvantages_of_tight_coupling">Disadvantages of tight coupling</h2></div>

Tightly coupled systems tend to exhibit the following developmental characteristics, which are often seen as disadvantages:

<ol><li>A change in one module usually forces a <a href="Ripple_effect" title="Ripple effect">ripple effect</a> of changes in other modules.</li>

<li>Assembly of modules might require more effort and/or time due to the increased inter-module dependency.</li>

<li>A particular module might be harder to <a href="Code_reuse" title="Code reuse">reuse</a> and/or test because dependent modules must be included.</li></ol>

<div class="mw-heading mw-heading2"><h2 id="Performance_issues">Performance issues</h2></div>

Whether loosely or tightly coupled, a system's performance is often reduced by message and parameter creation, transmission, translation (e.g. marshaling) and message interpretation (which might be a reference to a string, array or data structure), which require less overhead than creating a complicated message such as a <a href="SOAP" title="SOAP">SOAP</a> message. Longer messages require more CPU and memory to produce. To optimize runtime performance, message length must be minimized and message meaning must be maximized.

<dl><dt>Message Transmission Overhead and Performance</dt>

<dd>Since a message must be transmitted in full to retain its complete meaning, message transmission must be optimized. Longer messages require more CPU and memory to transmit and receive. Also, when necessary, receivers must reassemble a message into its original state to completely receive it. Hence, to optimize runtime performance, message length must be minimized and message meaning must be maximized.</dd></dl>

<dl><dt>Message Translation Overhead and Performance</dt>

<dd>Message protocols and messages themselves often contain extra information (i.e., packet, structure, definition and language information). Hence, the receiver often needs to translate a message into a more refined form by removing extra characters and structure information and/or by converting values from one type to another. Any sort of translation increases CPU and/or memory overhead. To optimize runtime performance, message form and content must be reduced and refined to maximize its meaning and reduce translation.</dd></dl>

<dl><dt>Message Interpretation Overhead and Performance</dt>

<dd>All messages must be interpreted by the receiver. Simple messages such as integers might not require additional processing to be interpreted. However, complex messages such as <a href="SOAP" title="SOAP">SOAP</a> messages require a parser and a string transformer for them to exhibit intended meanings. To optimize runtime performance, messages must be refined and reduced to minimize interpretation overhead.</dd></dl>

<div class="mw-heading mw-heading2"><h2 id="Solutions">Solutions</h2></div>

One approach to decreasing coupling is <a href="Functional_design" title="Functional design">functional design</a>, which seeks to limit the responsibilities of modules along functionality. Coupling increases between two classes A and B if:

<ul><li>A has an attribute that refers to (is of type) B.</li>

<li>A calls on services of an object B.</li>

<li>A has a method that references B (via return type or parameter).</li>

<li>A is a subclass of (or implements) class B.</li></ul>

Low coupling refers to a relationship in which one module interacts with another module through a simple and stable interface and does not need to be concerned with the other module's internal implementation (see <a href="Information_Hiding" class="mw-redirect" title="Information Hiding">Information Hiding</a>).

Systems such as <a href="CORBA" class="mw-redirect" title="CORBA">CORBA</a> or <a href="Component_Object_Model" title="Component Object Model">COM</a> allow objects to communicate with each other without having to know anything about the other object's implementation. Both of these systems even allow for objects to communicate with objects written in other languages.

<div class="mw-heading mw-heading2"><h2 id="Coupling_vs_Connascence">Coupling vs Connascence</h2></div>

Coupling describes the degree and nature of dependency between software components, focusing on what they share (e.g., data, control flow, technology) and how tightly they are bound. It evaluates two key dimensions: strength, which measures how difficult it is to change the dependency, and scope (or visibility), which indicates how widely the dependency is exposed across modules or boundaries. Traditional coupling types typically include content coupling, common coupling, control coupling, stamp coupling, external coupling, and data coupling. <a href="#cite_note-:03-9">[9]</a><a href="#cite_note-:12-10">[10]</a><a href="#cite_note-:2-11">[11]</a>

<a href="Connascence" title="Connascence">Connascence</a>, introduced by Meilir Page-Jones, provides a systematic framework for analyzing and measuring coupling dependencies. It evaluates dependencies based on three dimensions: strength, which measures the effort required to refactor or modify the dependency; locality, which considers how physically or logically close dependent components are in the codebase; and degree, which measures how many components are affected by the dependency. Connascence can be categorized into static (detectable at compile-time) and dynamic (detectable at runtime) forms. Static connascence refers to compile-time dependencies, such as method signatures, while dynamic connascence refers to runtime dependencies, which can manifest in forms like connascence of timing, values, or algorithm. <a href="#cite_note-:03-9">[9]</a><a href="#cite_note-:12-10">[10]</a><a href="#cite_note-:2-11">[11]</a>

Each coupling flavor can exhibit multiple types of connascence, a specific type, or, in rare cases, none at all, depending on how the dependency is implemented. Common types of connascence include connascence of name, type, position, and meaning. Certain coupling types naturally align with specific connascence types; for example, data coupling often involves connascence of name or type. However, not every combination of coupling and connascence is practically meaningful. Dependencies relying on parameter order in a method signature demonstrate connascence of position, which is fragile and difficult to refactor because reordering parameters breaks the interface. In contrast, connascence of name, which relies on field or parameter names, is generally more resilient to change. Connascence types themselves exhibit a natural hierarchy of strength, with connascence of name typically considered weaker than connascence of meaning. <a href="#cite_note-:03-9">[9]</a><a href="#cite_note-:12-10">[10]</a><a href="#cite_note-:2-11">[11]</a>

Dependencies spanning module boundaries or distributed systems typically have higher coordination costs, increasing the difficulty of refactoring and propagating changes across distant boundaries. Modern practices, such as dependency injection and interface-based programming, are often employed to reduce coupling strength and improve the maintainability of dependencies. <a href="#cite_note-:03-9">[9]</a><a href="#cite_note-:12-10">[10]</a><a href="#cite_note-:2-11">[11]</a>

While coupling identifies what is shared between components, connascence evaluates how those dependencies behave, how changes propagate, and how difficult they are to refactor. Strength, locality, and degree are interrelated; dependencies with high strength, wide scope, and spanning distant boundaries are significantly harder to refactor and maintain. Together, coupling provides a high-level overview of dependency relationships, while connascence offers a granular framework for analyzing dependency strength, locality, degree, and resilience to change, supporting the design of maintainable and robust systems. <a href="#cite_note-:03-9">[9]</a><a href="#cite_note-:12-10">[10]</a><a href="#cite_note-:2-11">[11]</a>

<div class="mw-heading mw-heading2"><h2 id="Coupling_versus_cohesion">Coupling versus cohesion</h2></div>

Coupling and <a href="Cohesion_(computer_science)" title="Cohesion (computer science)">cohesion</a> are terms which occur together very frequently. Coupling refers to the interdependencies between modules, while cohesion describes how related the functions within a single module are. Low cohesion implies that a given module performs tasks which are not very related to each other and hence can create problems as the module becomes large.

<div class="mw-heading mw-heading2"><h2 id="Module_coupling">Module coupling</h2></div>

Coupling in Software Engineering<a href="#cite_note-Pressman_1982-12">[12]</a> describes a version of metrics associated with this concept.

For data and control flow coupling:

<ul><li>di: number of input data parameters</li>

<li>ci: number of input control parameters</li>

<li>do: number of output data parameters</li>

<li>co: number of output control parameters</li></ul>

For global coupling:

<ul><li>gd: number of global variables used as data</li>

<li>gc: number of global variables used as control</li></ul>

For environmental coupling:

<ul><li>w: number of modules called (fan-out)</li>

<li>r: number of modules calling the module under consideration (fan-in)</li></ul>

</mrow>

<mfrac>

<mrow>

<msub>

</mrow>

</msub>

<msub>

</mrow>

</msub>

<msub>

</mrow>

</msub>

<msub>

</mrow>

</msub>

<msub>

</mrow>

</msub>

<msub>

</mrow>

</msub>

</mrow>

</mfrac>

</mrow>

</mstyle>

</mrow>

<annotation encoding="application/x-tex">{\displaystyle \mathrm {Coupling} (C)=1-{\frac {1}{d_{i}+2\times c_{i}+d_{o}+2\times c_{o}+g_{d}+2\times g_{c}+w+r}}}</annotation>

</semantics>

</math><img src="./7972c57de19863495a63d39a3a03d028ba3070ab.svg" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -2.338ex; width:67.636ex; height:5.676ex;" alt="{\displaystyle \mathrm {Coupling} (C)=1-{\frac {1}{d_{i}+2\times c_{i}+d_{o}+2\times c_{o}+g_{d}+2\times g_{c}+w+r}}}" loading="lazy">

<code>Coupling(C)</code> makes the value larger the more coupled the module is. This number ranges from approximately 0.67 (low coupling) to 1.0 (highly coupled)

For example, if a module has only a single input and output data parameter

<mfrac>

<mrow>

</mrow>

</mfrac>

</mrow>

<mfrac>

</mfrac>

</mrow>

</mstyle>

</mrow>

<annotation encoding="application/x-tex">{\displaystyle C=1-{\frac {1}{1+0+1+0+0+0+1+0}}=1-{\frac {1}{3}}=0.67}</annotation>

</semantics>

</math><img src="./dbc88b78f3adb05ad566574219038fcf17ae3bd9.svg" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -2.005ex; width:55.219ex; height:5.343ex;" alt="{\displaystyle C=1-{\frac {1}{1+0+1+0+0+0+1+0}}=1-{\frac {1}{3}}=0.67}" loading="lazy">

If a module has 5 input and output data parameters, an equal number of control parameters, and accesses 10 items of global data, with a fan-in of 3 and a fan-out of 4,

<mfrac>

<mrow>

</mrow>

</mfrac>

</mrow>

</mstyle>

</mrow>

<annotation encoding="application/x-tex">{\displaystyle C=1-{\frac {1}{5+2\times 5+5+2\times 5+10+0+3+4}}=0.98}</annotation>

</semantics>

</math><img src="./86f12badf6ce5c6523900dc9a3562afeeb993664.svg" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -2.005ex; width:55.287ex; height:5.343ex;" alt="{\displaystyle C=1-{\frac {1}{5+2\times 5+5+2\times 5+10+0+3+4}}=0.98}" loading="lazy">

<ul><li><a href="Connascence_(computer_science)" class="mw-redirect" title="Connascence (computer science)">Connascence (computer science)</a></li>

<li><a href="Coupling_(physics)" title="Coupling (physics)">Coupling (physics)</a></li>

<li><a href="Dead_code_elimination" class="mw-redirect" title="Dead code elimination">Dead code elimination</a></li>

<li><a href="Dependency_hell" title="Dependency hell">Dependency hell</a></li>

<li><a href="Efferent_coupling" title="Efferent coupling">Efferent coupling</a></li>

<li><a href="Inversion_of_control" title="Inversion of control">Inversion of control</a></li>

<li><a href="List_of_object-oriented_programming_terms" class="mw-redirect" title="List of object-oriented programming terms">List of object-oriented programming terms</a></li>

<li><a href="Loose_coupling" title="Loose coupling">Loose coupling</a></li>

<li><a href="Make_(software)" title="Make (software)">Make (software)</a></li>

<li><a href="Static_code_analysis" class="mw-redirect" title="Static code analysis">Static code analysis</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="References">References</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .reflist{margin-bottom:0.5em;list-style-type:decimal}@media screen{.mw-parser-output .reflist{font-size:90%}}.mw-parser-output .reflist .references{font-size:100%;margin-bottom:0;list-style-type:inherit}.mw-parser-output .reflist-columns-2{column-width:30em}.mw-parser-output .reflist-columns-3{column-width:25em}.mw-parser-output .reflist-columns{margin-top:0.3em}.mw-parser-output .reflist-columns ol{margin-top:0}.mw-parser-output .reflist-columns li{page-break-inside:avoid;break-inside:avoid-column}.mw-parser-output .reflist-upper-alpha{list-style-type:upper-alpha}.mw-parser-output .reflist-upper-roman{list-style-type:upper-roman}.mw-parser-output .reflist-lower-alpha{list-style-type:lower-alpha}.mw-parser-output .reflist-lower-greek{list-style-type:lower-greek}.mw-parser-output .reflist-lower-roman{list-style-type:lower-roman}

/* end https://en.wikipedia.org/ */

</style><div class="reflist">

<li id="cite_note-ISO_24765-1"><a href="#cite_ref-ISO_24765_1-0">^</a> ISO/IEC/IEEE 24765:2010 Systems and software engineering — Vocabulary

</li>

<li id="cite_note-ISOIECTR19759_2005-2"><a href="#cite_ref-ISOIECTR19759_2005_2-0">^</a> ISO/IEC TR 19759:2005, Software Engineering — Guide to the Software Engineering Body of Knowledge (SWEBOK)

</li>

/* start https://en.wikipedia.org/ */

.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output .id-lock-free.id-lock-free a{background:url("./mw/Lock-green.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-limited.id-lock-limited a,.mw-parser-output .id-lock-registration.id-lock-registration a{background:url("./mw/Lock-gray-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-subscription.id-lock-subscription a{background:url("./mw/Lock-red-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .cs1-ws-icon a{background:url("./mw/Wikisource-logo.svg")right 0.1em center/12px no-repeat}body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-free a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-limited a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-registration a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-subscription a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .cs1-ws-icon a{background-size:contain;padding:0 1em 0 0}.mw-parser-output .cs1-code{color:inherit;background:inherit;border:none;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;color:var(--color-error,#d33)}.mw-parser-output .cs1-visible-error{color:var(--color-error,#d33)}.mw-parser-output .cs1-maint{display:none;color:#085;margin-left:0.3em}.mw-parser-output .cs1-kern-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflink{font-weight:inherit}@media screen{.mw-parser-output .cs1-format{font-size:95%}html.skin-theme-clientpref-night .mw-parser-output .cs1-maint{color:#18911f}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .cs1-maint{color:#18911f}}

/* end https://en.wikipedia.org/ */

</style><cite id="CITEREFHohpe" class="citation book cs1">Hohpe, Gregor. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley Professional. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-0321200686</bdi>.</cite>

</li>

<li id="cite_note-Stevens_1974-4"><a href="#cite_ref-Stevens_1974_4-0">^</a> <cite id="CITEREFStevensMyersConstantine1974" class="citation journal cs1"><a href="Wayne_Stevens_(software_engineer)" title="Wayne Stevens (software engineer)">Stevens, Wayne P.</a>; <a href="Glenford_J._Myers" class="mw-redirect" title="Glenford J. Myers">Myers, Glenford J.</a>; <a href="Larry_LeRoy_Constantine" class="mw-redirect" title="Larry LeRoy Constantine">Constantine, Larry LeRoy</a> (June 1974). "Structured design". <a href="IBM_Systems_Journal" class="mw-redirect" title="IBM Systems Journal">IBM Systems Journal</a>. 13 (2): 115–139. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1147%2Fsj.132.0115">10.1147/sj.132.0115</a>.</cite>

</li>

<li id="cite_note-Yourdon_1979-5"><a href="#cite_ref-Yourdon_1979_5-0">^</a> <cite id="CITEREFYourdonConstantine1979" class="citation book cs1"><a href="Edward_Yourdon" title="Edward Yourdon">Yourdon, Edward</a>; <a href="Larry_LeRoy_Constantine" class="mw-redirect" title="Larry LeRoy Constantine">Constantine, Larry LeRoy</a> (1979) [1975]. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. Yourdon Press. <a href="Bibcode_(identifier)" class="mw-redirect" title="Bibcode (identifier)">Bibcode</a>:<a rel="nofollow" class="external text" href="https://ui.adsabs.harvard.edu/abs/1979sdfd.book.....Y">1979sdfd.book.....Y</a>. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-0-13-854471-3</bdi>.</cite>

</li>

<li id="cite_note-6"><a href="#cite_ref-6">^</a> <cite id="CITEREFRichards" class="citation book cs1">Richards, Mark. Fundamentals of Software Architecture: An Engineering Approach. O'Reilly Media. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-1492043454</bdi>.</cite>

</li>

<li id="cite_note-Beck_2011-7"><a href="#cite_ref-Beck_2011_7-0">^</a> <cite id="CITEREFBeckDiehl2011" class="citation book cs1">Beck, Fabian; Diehl, Stephan (September 2011). "On the Congruence of Modularity and Code Coupling". In Proceedings of the 19th ACM SIGSOFT Symposium and the 13th European Conference on Foundations of Software Engineering (SIGSOFT/FSE '11). Szeged, Hungary. p. 354. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1145%2F2025113.2025162">10.1145/2025113.2025162</a>. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>9781450304436</bdi>. <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:2413103">2413103</a>.</cite><code class="cs1-code">{{cite book}}</code>: CS1 maint: location missing publisher (link)

</li>

<li id="cite_note-Arisholm_2004-8"><a href="#cite_ref-Arisholm_2004_8-0">^</a> <cite id="CITEREFArisholmBriandFøyen2004" class="citation journal cs1">Arisholm, Erik; <a href="Lionel_C._Briand" class="mw-redirect" title="Lionel C. Briand">Briand, Lionel C.</a>; Føyen, Audun (August 2004). "Dynamic coupling measurement for object-oriented software". <a href="IEEE_Transactions_on_Software_Engineering" title="IEEE Transactions on Software Engineering">IEEE Transactions on Software Engineering</a>. 30 (8). <a href="IEEE" class="mw-redirect" title="IEEE">IEEE</a>: 491–506. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1109%2FTSE.2004.41">10.1109/TSE.2004.41</a>. <a href="Hdl_(identifier)" class="mw-redirect" title="Hdl (identifier)">hdl</a>:<a rel="nofollow" class="external text" href="https://hdl.handle.net/10852%2F9090">10852/9090</a>. <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:3074827">3074827</a>.</cite>

</li>

<li id="cite_note-:03-9">^ <a href="#cite_ref-:03_9-0">a</a> <a href="#cite_ref-:03_9-1">b</a> <a href="#cite_ref-:03_9-2">c</a> <a href="#cite_ref-:03_9-3">d</a> <a href="#cite_ref-:03_9-4">e</a> <cite class="citation book cs1">Practical Guide to Structured Systems Design. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-0136907695</bdi>.</cite>

</li>

<li id="cite_note-:12-10">^ <a href="#cite_ref-:12_10-0">a</a> <a href="#cite_ref-:12_10-1">b</a> <a href="#cite_ref-:12_10-2">c</a> <a href="#cite_ref-:12_10-3">d</a> <a href="#cite_ref-:12_10-4">e</a> <cite class="citation book cs1">Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-1449373320</bdi>.</cite>

</li>

<li id="cite_note-:2-11">^ <a href="#cite_ref-:2_11-0">a</a> <a href="#cite_ref-:2_11-1">b</a> <a href="#cite_ref-:2_11-2">c</a> <a href="#cite_ref-:2_11-3">d</a> <a href="#cite_ref-:2_11-4">e</a> <cite class="citation book cs1">Fundamentals of Software Architecture: An Engineering Approach. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-1492043454</bdi>.</cite>

</li>

<li id="cite_note-Pressman_1982-12"><a href="#cite_ref-Pressman_1982_12-0">^</a> <cite id="CITEREFPressman1982" class="citation book cs1"><a href="Roger_S._Pressman" title="Roger S. Pressman">Pressman, Roger S.</a> (1982). <a rel="nofollow" class="external text" href="https://archive.org/details/softwareengineer00pres_0">Software Engineering - A Practitioner's Approach</a> (4 ed.). McGraw-Hill. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>0-07-052182-4</bdi>.</cite>

</li>

</ol></div></div>

<div class="mw-heading mw-heading2"><h2 id="Further_reading">Further reading</h2></div>

<ul><li><cite id="CITEREFMyers1974" class="citation book cs1"><a href="Glenford_J._Myers" class="mw-redirect" title="Glenford J. Myers">Myers, Glenford J.</a> (1974). Reliable Software through Composite Design. New York: Mason and Lipscomb Publishers.</cite></li>

<li><cite id="CITEREFOffuttHarroldKolte1993" class="citation journal cs1">Offutt, A. Jefferson; <a href="Mary_Jean_Harrold" title="Mary Jean Harrold">Harrold, Mary Jean</a>; Kolte, Priyadarshan (March 1993). "A Software Metric System for Module Coupling". <a href="Journal_of_Systems_and_Software" title="Journal of Systems and Software">Journal of Systems and Software</a>. 20 (3): 295–308. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1016%2F0164-1212%2893%2990072-6">10.1016/0164-1212(93)90072-6</a>.</cite></li>

<li><cite id="CITEREFPage-Jones1980" class="citation book cs1">Page-Jones, Meilir (1980). The Practical Guide to Structured Systems Design. New York: Yourdon Press. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-8-12031482-5</bdi>.</cite></li>

<li><cite class="citation book cs1">Standard Glossary of Software Engineering Terminology. New York: <a href="IEEE" class="mw-redirect" title="IEEE">IEEE</a>. 1990. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>0-7381-0391-8</bdi>. 610.12_1990.</cite></li>

<li><cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://web.archive.org/web/20170329132933/http://www.isaqb.org/wp-content/uploads/2015/05/isaqb-Curriculum-foundation-v3-MAY-2015-EN.pdf">"Curriculum for Certified Professional for Software Architecture (CPSA) - Foundation Level"</a> (PDF). 3.01. International Software Architecture Qualification Board e.V. (ISAQB). 2015-05-15 [2009]. Archived from <a rel="nofollow" class="external text" href="https://www.isaqb.org/wp-content/uploads/2015/05/isaqb-Curriculum-foundation-v3-MAY-2015-EN.pdf">the original</a> (PDF) on 2017-03-29. Retrieved 2019-06-23.</cite> <a rel="nofollow" class="external autonumber" href="http://www.isaqb.org/wp-content/uploads/2015/05/isaqb-Lehrplan-foundation-v3-MAI-2015-DE.pdf">[1]</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20160222052330/http://www.isaqb.org/wp-content/uploads/2015/05/isaqb-Lehrplan-foundation-v3-MAI-2015-DE.pdf">Archived</a> 2016-02-22 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a></li></ul></div><div><div class="zim-footer">

This article is issued from <a class="external text" title="Last edited on 2025-07-24" href="https://en.wikipedia.org/wiki/?title=Coupling_(computer_programming)&oldid=1302292090">Wikipedia</a>. The text is available under <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.en">Creative Commons Attribution-Share Alike 4.0</a> unless otherwise noted. Additional terms may apply for the media files.

</div>

</div></div>

</div>

</main>

</div>

</body></html>